As pointed out by C. J. Date, "An Introduction to Data Base Systems", Vol. 1, 4th Edition, Addison-Wesley Publishing Co., copyright 1986, Ch. 18, a "transaction" is a logical unit of work referencing a sequence of operations that transforms a consistent state of a recoverable resource into another consistent state without necessarily preserving consistency at all intermediate points. For purposes of this discussion, a data base will be referenced as a typical instance of a recoverable resource.
A system supporting transaction processing guarantees that if the transaction executes some updates against the data base and a failure occurs before the transaction reaches its normal termination, then those updates will be undone. Consequently, the transaction either executes in its entirety or it is totally cancelled. Since a transaction comprises execution of an application-specified sequence of operations, it is initiated with a special BEGIN transaction operation and ends with either a COMMIT operation or an ABORT operation. The COMMIT and ABORT operations are the key to providing atomicity.
The COMMIT operation signifies several attributes. First, it indicates that a transaction has successfully terminated. Second, it indicates that the data base is in a consistent state. Lastly, the COMMIT operation indicates that all of the updates made by that unit of work can now be committed or made permanent. In contrast, the ABORT operation signifies an unsuccessful end of transaction. That is, the ABORT means that a fault has occurred, that the data base may be in an inconsistent state, and that all of the updates made by the transaction must be "rolled back" or undone.
Transactions are executed on stored program-controlled systems whose logical and physical attributes are generically denominated "resources". Also, such systems may be considered to operate in modes such as a "processing" mode or, in the event of failure, one or more "recovery" modes. Control of both the access to and the operation of the resources is exercised by operating system (OS) software. These and denomiated "resource managers". Similarly, the transaction-oriented processing and recovery operations are governed by OS software denomiated "transaction processing" and "recovery managers".
As pointed out by Deitel, "An Introduction to Operating Systems", Revised 1st Edition, Addision-Wesley Publishing Co., copyright 1984, pp. 103-108, resource managers may be thought of as "monitors". A monitor is a concurrency construct that contains both the data and procedures needed to perform allocation of a particular shared resource or group of shared resources. That is, a monitor is a mechanism that allows the safe and effective sharing of abstract data types among several processes.
In a transaction-oriented data base system, all changes to the data base are written to a log in support of recovery in the event of interruption. Each transaction utilizes BEGIN, COMMIT, ABORT, or END primitives in order to bound the COMPLETION, UNDO, or REDO of each transaction.
It may be observed that a checkpoint record is a list of all transactions alive at the time of the checkpoint, together with the log address of each transaction's most recent log record. A transaction whose records are used in its REDO is a transaction that has terminated (committed) between the last checkpoint and the occurrence of failure, whereas a transaction whose records are used in its UNDO is one that has not terminated at the time of the occurrence of failure. Thus, REDOs require transaction return to the most recent COMMIT point, while UNDOs require return to the transaction BEGIN point.
It should be appreciated that transactions define not only the unit of work, but also a unit of recovery. It is necessary for the system to know at restart or recovery time which transactions to UNDO and which to REDO. The snapshot or checkpoint taken at predetermined times certainly lists all transactions that were in progress at the time the checkpoint was taken. Thus, depending on the point in time when a failure occurred, the system can construct an UNDO list and a REDO list by working backward through the log, undoing the transactions in the UNDO list, and then working forward again, redoing the transactions in the REDO list. Only when all such recovery activity is completed can the system be in a position to accept any new work. Strictly speaking, it is the checkpoint plus succeeding log activity which must be processed to affirm the UNDO and REDO lists.
In the prior art, several references describe fault-tolerant, transaction-oriented data base systems. These include:
(1) Gawlick et al, U.S. Pat. No. 4,507,751, "Method and Apparatus for Logging Journal Data Using a Log Write Ahead Data Set", issued Mar. 26, 1985.
(2) Baker et al, U.S. Pat. No. 4,498,145, "Method and Apparatus for Assuring Atomicity of Multirow Update Operations in a Database System", issued Feb. 5, 1985.
(3) Paradine et al, U.S. Pat. No. 4,159,517, "Journal Back-up Storage Control for a Data Processing System", issued June 26, 1979.
(4) Reinsch et al, "Method for Restarting a Long-running, Fault-tolerant Operation in a Transaction-oriented Data Base System Without Burdening the System Log", copending U.S. Ser. No. 06/835,396, filed Mar. 3, 1986.
(5) Jenner, "Method and Apparatus for Restarting a Computing System", copending U.S. application Ser. No. 06/390,163, filed June 21, 1982.
The current logging technology represented by the references writes all log data produced by a transaction-oriented system into a single stream of data physically resident at a point in time on multiple DASD or tape devices with only one device being written upon at each instant. The Gawlick, Baker, and Paradine patents and the copending Reinsch and Tenner applications respectively describe (1) the writing to a log before record updating, (2) buffer dumping to a log, (3) writing to a hard and soft log concurrently to assure multirow atomic updating, (4) the utilization of a restartable load utility in which all changes to the data base are typically written to a log in support of recovery in the event of interruption, and (5) updating state tables of the subsystem components as to their recovery dependencies in the event of restart to assist actual restart of a log-based transaction system caused by randomly occurring faults.
The art also distinguishes the types of information required in the failure recovery of a system from that involved in the failure recovery of a resource. System recovery involves bringing system resources to a prior state of consistency, while resource recovery involves the recreation of a consistent image of a resource after it has been corrupted.
The art uses certain terms as synonyms. For instance, the "control" and/or "information state" of a resource or a system may also be termed its "image". In transaction processing, this would most frequently reference the data sets memorializing transactions.